Allison had read Men Are From Mars, Women Are From Venus, but right now she was trying to figure out which obscure part of the cosmos her company's programmers called home. Quite remarkably, the programmers looked like Earth people, and even spoke in a language that often resembled English. However, as the lead programmer on the other end of the telephone babbled excitedly about the URL he had just sent Allison to, it was obvious that his alien senses were perceiving objects that were invisible to mere humans.

"See! The ordering applet displays the online catalog, lets you select products, and fires off the transactions through the gateway to the main DBMS!"

Allison didn't see. All she could see was an empty square in the middle of her screen. Every time she'd ever come to this part of the system, she'd seen the same blank square. No matter how she squinted at it, it had never looked, to her eyes, the least bit like an online ordering system. It looked like a screen with a big blank patch in the middle of it.

As a result, she'd always clicked on over to other web pages looking for a way to place orders. Despite persistent rumors of its existence, she'd never actually beheld the apparent wonder which was the company's online ordering applet. Neither had most of her company's customers. After she'd made a few calls to technical support, one of the programmers had called to help her out.

A minute of uncomfortable silence passed, and Allison could take no more. "Look, I don't mean to be rude, but what the heck are you talking about? There's nothing there!"

"Oh!" said the programmer, startled that there was a problem. "Well, there will be in a few minutes. It must still be loading."

SPEED MATTERS

While computers themselves are increasing in performance at incredible rates, the web remains one of the few areas where speed is hard to come by. For most users, communication speed is pegged at a mere 28.8 Kbps or below, and network delays bog down even those lucky enough to have ISDN or T1 lines. Adding to this, the current implementations of many network browsers and development environments leave much to be desired in terms of performance.

The good news is that although speed matters, perceived speed matters even more. For the most part, the thing that makes users crazy is not the amount of actual time that goes by, but the feeling of waiting -- little delays before the computer reacts to their input, or the long seconds they spend sitting around with nothing to do while the computer works to complete a task. Luckily, although we often can't control the computer's absolute speed, we can employ a number of tricks to make the computer feel faster. At the same time we can also keep the user better informed of what we're doing. The result is that our programs and web pages will seem faster to users, although the actual speed may not have changed at all.

STUPID USER TRICKS

The first number, 200 milliseconds -- a mere 0.2 seconds -- forms the mental boundary between events that seem to happen together and those that appear merely as echoes of each other. If a computer program responds less than 200 ms after the user's actions, it will seem fluid and responsive. Any more than 200 ms and the computer will seem frustratingly sluggish. That frustration plays a key role in our second number. To explain it, I'd like to tell you about a little experiment of mine.

For this devious little adventure in science, I recruited almost two dozen expert typists and asked them to fill out a big stack of forms in exchange for a free "Usability Testing" T-shirt. They were told that the purpose of the experiment was to find out what sorts of user interface elements (radio buttons, text fields, pop-up menus, and so on) were the quickest for data entry. Indeed, that was one goal of the experiment. The main purpose, however, was a bit more sinister.

As test subjects showed up for the experiment, I sat them down with a stack of forms to fill out and explained that the computer would be collecting information on their speed and accuracy, and that if they needed anything I could be reached back at my office. After showing them how to fill out a sample form, I started the video camera rolling and left the room.

What the subjects didn't know was that the test was rigged. After the user clicked the Save button on the 28th form, the computer would go into a hard wait loop for two minutes. After that, the program would continue normally.

Of course, nobody ever got that far. Instead, they'd click the Save button repeatedly, grimace a bit, mutter a few unprintables, and then either get up and look for me to fix things, or -- a bit more than half the time -- reach over and reboot the machine. What I was really trying to find out was how long they would wait before they either gave up and rebooted the machine or walked out of the room altogether.

The answer was much shorter than I'd imagined. In the original test, the users weren't given so much as a watch cursor to convince them that the computer was working on their problem. According to an analysis of the video tapes, it took only 8.5 seconds for half the subjects to either walk out or hit the reboot switch. Switching to a watch cursor during the wait delayed the subject's departure for about 20 seconds. An animated watch cursor was good for over a minute, and a progress bar would keep them waiting until the Second Coming -- or Windows 98, whichever came first.

So what does it all mean? First, when the user performs an action, your program needs to respond immediately, even if just to change the cursor. For longer waits, make sure you display some sort of message to let the user know what you're doing and how long it will take. In doing so, avoid relying too heavily on browser status line displays, which are easily overlooked and can change before the user sees them. Above all, keep your users informed -- or it will take only about 8.5 seconds for them to give up on your application.

SPEEDING IT UP

React immediately.

However, on the page level, with all these elements combined, things slow down dramatically. Still, you can greatly boost the perceived speed of your pages by minimizing the use of graphics, or by trimming down -- or using frames to isolate -- the parts that must be redrawn in order to update the page in response to user input.

Do visible work first.

If you write Java applets, structure them to bring up a splash screen or other display as quickly as is technically possible. This will reassure the user that the application is working properly, and it will buy you additional time to load the application before the user becomes anxious.

Let the user move on quickly.

Try to locate your navigational elements near the top of the page, or in a separate frame that won't need to be redrawn every time the user moves from page to page. If you use graphics for navigation, always use the <IMG> tag's alt= attribute to provide users with the names of navigation buttons without requiring them to wait for the actual graphic to load. In addition, make sure you've specified the height and width for your graphics so that the browser can draw their bounding areas immediately, and try to use the same images throughout so that the graphics can be cached by the browser and retrieved quickly when needed.

If your system includes image maps, consider using the lowsrc= attribute to immediately load in a black and white or other, more quickly drawn version of the graphic. This will often provide all the information the user needs to move on, although more patient users will see the full-color version automatically as soon as the rest of the page is done loading.

Keep the user posted.

With straight HTML, you'll have to rely on your web browser's status line for this, limited though it may be. Java applets face additional problems in this area. Their larger size and resource requirements often make them take far longer to load than a standard HTML page. What's more, most browsers do little more than display a blank screen area while the applet is loading, sometimes accompanied by an ambiguous "applet loading" message buried at the bottom of the screen. Luckily, Java applets that go the extra mile can incorporate real feedback mechanisms such as progress bars and other displays to keep the user informed. These involve additional work for the programmer, but they're absolutely crucial if we expect users to wait far beyond the critical 8.5 seconds before the applets begin executing.